先撤掉四段免费代码，再谈要不要换那台五千八的服务器

三月中旬的周会上，一家有八家门诊的口腔连锁市场负责人把手机横在桌上，屏幕停在白屏，进度条卡在四分之一处。他没说话，等了大概八秒，页面才把顶部那张种植牙广告图刷出来。老板当场问技术代理商的第一句话是：是不是服务器该换了。对方给的方案是从两核四G升到八核十六G，一年多付五千八百元，并且建议同时加一台数据库实例。

这个站是四年前做的，当时的网站建设合同里写了三年维护，去年到期后就没再续，中间陆续加过预约表单、投放落地页和一个在线咨询挂件。接手排查的时候我们只提了一个要求：先把不花钱的项目全部做完，再决定要不要签那份升级单。

先量三个数，一分钱不用花

第一件事不是改代码，是取真实数据。我们让市场部主管用他自己那台用了三年多的安卓机，站在三楼门诊的电梯间——信号常年只有一格——打开官网首页，用秒表计时，连测五次，取中间值是八点六秒。同一台机器连门诊 WiFi 再测，是三点一秒。这两个数字之间的落差，后面成了所有取舍的判断依据：办公室里看着能用的站，在真实就诊场景里未必能用。这套测法不需要任何工具，网站建设验收时本来就该这么测，只是四年前没人提。

第二个数来自浏览器自带的网络面板。首页一共发出一百一十八个请求，传输体积四点三兆。第三个数是首字节时间，一点九秒。这三项加起来已经能大致定位方向：首字节接近两秒说明服务端确实在等什么，但四点三兆和一百一十八个请求说明前端的问题只会更大。如果这时候直接换服务器，最好的情况也只是把那一点九秒压下去一部分，剩下六秒多原封不动。

后台里躺着四段没人记得的代码

把请求列表按耗时倒序排，排在第一位的不是图片，是一个陌生域名下的脚本，单项耗时四点八秒，状态是连接超时。查下来是二零二二年上线一次活动页时接入的热力图工具，那家服务商早就关停了，域名还能解析，服务器却不再应答，浏览器要一直等到超时才肯继续往下渲染。这段代码写在页面头部，是同步加载，等于每一个访客进站都要先替这家倒闭的公司站四秒多的岗。

顺着往下清，后台的自定义代码框里一共躺着四段：一段是在用的流量统计，一段是某投放平台的转化回传（那个账户两年前就停投了），一段就是上面那个热力图，还有一段是当初做站时预埋的客服系统旧版本，后来换了新客服却忘了删，两套客服脚本同时在跑。撤掉三段废的，只需要在后台点几下，不涉及任何开发工时。改完再用同一台旧手机在同一个电梯间测，八点六秒变成三点九秒。

这一步的收益占了整个项目的一半以上，成本是零。网站建设交付之后的三五年里，这类沉积几乎必然发生：每一次投放、每一次活动、每一次换供应商，都会往页面头部塞一段，而没有任何流程负责在活动结束后把它取出来。

两个小时能改完的三处服务端设置

接下来动的三处都在服务器配置文件里，不改一行业务代码。第一处是传输压缩没开，一个二百四十六K的样式表原样传给用户，开启之后是三十四K，三个脚本文件合计五百二十K压到一百四十三K。第二处是浏览器缓存策略，静态资源全都没有设过期时间，老客户每次回访都重新下载一遍，加上一年有效期之后，第二次访问的请求数从一百一十八掉到十九。

第三处是中文字体。设计稿指定了一款商用中文字体，前端图省事直接引了完整字库，两点六兆，而且是渲染阻塞的。全站实际用到的汉字，我们用脚本扫了一遍页面模板加数据库里的标题字段，去重之后是一千四百多个字，做成子集包只有一百零八K。这一项在很多网站建设项目里都被当成设计问题，其实它是彻头彻尾的工程问题。三处做完，首屏进到二点七秒。

第九天把已经上线的东西改了回去

为了再抠掉半秒，我们把在线咨询挂件从头部同步加载改成了滚动触发：访客第一次向下滚动时才去拉那个SDK。首屏数字确实好看了，问题在第九天暴露出来——前台反馈说这几天在线咨询明显变少。调后台记录，日均咨询会话从十四次掉到六次。原因很直白：不少人打开首页看到电话号码和咨询按钮就要点，他们根本不滚动，而不滚动就没有按钮。

返工方案是把按钮和它背后的脚本拆开：按钮本身写成纯静态的HTML，页面出来就在，样式也不依赖脚本；只有当访客真的点下去，才现场加载SDK，加载期间按钮显示转圈。这样首屏体积没回涨，入口也没丢。改完的第二周咨询会话回到十五次，比改造前还高了一点，多出来的部分大概是从原先那批等不及走掉的人里捞回来的。这次返工额外花了半个开发日，本来可以不花——我们优化的是加载指标，忘了咨询按钮是这个行业最主要的转化入口。

一个测完就否掉的方案，和一笔没花的钱

八个门店页当时也在考虑范围里。技术上最优雅的做法是合并成一个页面，用切换控件在八家门店之间跳，这样能少七个页面的重复加载。我们没有直接全站上，先在两家门店灰度了两周。结果首屏脚本从六十K涨到二百一十K，更要命的是这两家门店页的自然搜索进入量从每周四十三次掉到二十九次——原来的独立页面各自带着门店所在路名的长尾词，合并之后这些词失去了落地页。两周后恢复原状，这个方案作废。

真正需要动代码的只剩下一处：门店列表页在渲染时，先查八家门店，再对每家门店查医生，再对每位医生查擅长项目标签，一次访问累计发出一百三十三条数据库查询。加了一层十分钟过期的静态缓存之后，同样的页面只查一次，首字节时间从一点九秒降到零点四秒。这一处花了三个开发日，是整个项目里最贵的一项，也是唯一一项如果不看数据就想不到的。

那台五千八的服务器最后没有换。六周结束时首屏稳定在二点四秒，CPU 峰值占用不到百分之三十，升配的理由自然消失了。额外花的钱只有一项内容分发网络，按流量计费，全年不到五百元。

六周之后的两笔账

能写进报价单的那一笔：开发六点五人日，其中三日在数据库缓存，一日在字体子集与压缩配置，半日在那次返工，剩下两日是测试和回归。另一笔账在客户自己这边，报价单上一个字都没有——市场部为了配合优化，重新导出了六十二张医生照片、核对了八家门店的营业时间和地址文案，前后投入将近四十个小时。这笔隐性工时在几乎所有网站建设项目里都存在，事先说清楚，客户的预期会稳很多。

效果这边也有变差的指标。移动端跳出率从百分之七十一降到百分之五十四，周均预约表单从十一条涨到十九条，但页面平均停留时长从两分十秒掉到一分四十秒。这个数一开始让人紧张，后来对照发现是因为原先有相当一部分停留时间是花在等加载上的——人还在，只是不用干等了。指标变差不一定是坏事，前提是你知道它为什么变。

刻意没有优化的那个页面

案例展示页我们一个字没改。那一页有四十多张术前术后对比图，加载要四秒多，是全站最慢的页面。不动的理由是统计数据：进这个页面的访客平均停留三分二十秒，其中六成会继续点到预约表单，他们已经处在决策末期，愿意等。把四秒压到两秒，对这批人的行为几乎没有影响，而同样的三个开发日放在首页上能换回十几条预约。

这件事最后留下两条能带走的判断。第一条是排查顺序要按改动成本排，不按技术含量排：先做在后台点几下就能撤销的，再做改配置文件的，最后才做动代码和动钱的——本项目里零成本那一档贡献了超过一半的提速。第二条是每个页面的耐心预算不一样，首屏大概是三秒，深度内容页可以到三十秒，优化资源应该照着预算缺口分配，而不是照着页面加载耗时排行榜从上往下做。